【レポート】AWS のサービスを使ったオンプレミスからのデータベース移行 #AWSSummit

こんにちは、崔です。

AWS Summit Online のセッション「AWS のサービスを使ったオンプレミスからのデータベース移行」を視聴しましたので、レポートをお届けします。
このセッションは、オンプレミスにあるデータベースをAWSへ移行する際に、どのような移行パターンがあるのか、また、AWSが提供するDMSやSCTをどのように利用すればいいのか、について語られています。

セッション情報

スピーカー

アマゾン ウェブ サービス ジャパン株式会社
技術統括本部
ソリューションアーキテクト 新久保 浩二 様

概要

オンプレミスのデータベースを AWS に移行する際の様々なパターンとその移行方法について説明します。 データベース移行の各フェーズで DMS/SCT がどのように活用できるのか、データベース移行を効率化する DMS/SCT の機能の特徴など基礎的なことを理解して頂きます。

資料

Agenda

• AWSにデータベースを移行する際のパターンと移行方法
  • 今回のセッションでは、例としてオンプレミスのOracleを移行対象とする
• Schema ConversionTool（SCT）／ Database Migration Service（DMS）の概要
• SCT/DMSを活用したデータベース移行の具体例
• まとめ

AWSにデータベースを移行する際のパターンと移行方法

考えられる移行パターン1 : Re-Host

• 既存のデータベース環境はできるだけ変更せず、そのままクラウド化する
• データベースのバージョンや運用方法もできるだけ変更しないことで、データベース移行に対するリスクを最小限に抑える

データベースエンジンを変更せず移行する場合

• Re-HostとRe-Platform
  • Re-Host：EC2にデータベースをインストール
  • Re-Platform：マネージドサービスであるRDSの利用

考えられる移行パターン2 : Re-Architecture

• 既存データベース環境のクラウド化と合わせて、アーキテクチャー変更も行う
  • 例えば、OracleからAmazon Aurora PostgreSQL に移行する
    • 商用DBエンジンからOSS系DBエンジンへの変更により、ライセンス問題を解決
    • Auroraを利用することで、AWSの他のサービスとも連携
    • ただし、DBエンジンを変えることで、周りのアプリケーションや関連するシステムにも影響あるので、充分に検証が必要
  • 難易度は高くなる

考えられる移行パターン3 : (Re-Host or Re-Platform）& Re-Architecture

• まずは、DBエンジンを変えずに、オンプレミスからAWSへ移行
• その後に、AWS上でDBエンジンを変えながら、Re-Architectureをしていく
• 二段階移行
  • 意外にこのパターンが多い
  • データセンターの契約切れなど、期間の短い中での対応が求められるケースなど

移行パターンと移行方針の整理

• カットオーバー時に十分な停止時間を取れる場合
  • ソースとターゲットが同一DBエンジンの場合
    • ダンプツールで移行
  • ソースとターゲットが異なるDBエンジンの場合
    • CSVアンロードで移行
• カットオーバー時に十分な停止時間が取れない場合
  • ソースDBとターゲットDBが同一DBエンジンの場合
    • DB純正のレプリケーションが組める場合
      • レプリケーションで移行
  • ソースDBとターゲットDBが異なるDBエンジンの場合
    • Database Migration Service で移行

移行の流れとAWSで提供するDB移行サービス

• OracleからPostgreSQLに移行する場合
  • SCT（Schema Conversion Tool）
    • アセスメント、評価の実施
    • スキーマ変換
    • コード変換（プロシージャ、アプリケーション）
  • DMS（Database Migration Service）
    • データ移行
    • テスト

SCT/DMSの概要

SCT

• データベースのスキーマを変換するツール

DMS

• データベース上のデータをマイグレーションするサービス
• ダウンタイムを最小化したデータ移行の実現

SCT/DMSを活用したデータベース移行の具体例

例

• オンプレミスのOracleからAurora PostgreSQLへの移行シナリオ
  • 最初の3つのステップをSCTで実施
    • オンプレミス側にSCTをインストールし、DBに接続
  • 後半の2つのステップをDMSで実施
    • VPNやDirect Connectなどのセキュアで安定したネットワークが必要

SCTによるデータベースの移行評価

• アセスメントレポートが作成される
• 自動変換できる割合
• 手動変換が必要な割合
  • 必要なアクションがランク分けされる
• 自動変換出来ない場合は指摘ポイントが出る

よく指摘されるポイント

• 主に次の3つ
  • オブジェクトの互換性
  • SQL、ビルトイン関数、データ型の互換性
  • ストアドプロシジャー、ビュー、トリガーなどの互換性

Database Migration Playbook

• AWSが提供しているDB移行のベストプラクティスのまとめ
• 手動変換が必要な場合は、参照すること

SCTによるスキーマ、コード変換

• 左側がソースDBのオブジェクト
• 右側がターゲットDBのオブジェクト
  • プロシージャのソースコードが表示されている
• 結果の整合性やパフォーマンスは担保できないので、テストの実施が重要

DMSを使ったデータ移行手順のイメージ

• DMSインスタンス（レプリケーションインスタンス）を作成
• ソース、ターゲットのエンドポイントを作成
• 移行タスクを作成（以下3つから選択）
  • フルロード
  • フルロード + CDC
  • CDCのみ
  • 必要なオブジェクトだけを選択可能

DMSを使った最小限のダウンタイムのデータ移行

• 初期データ移行（フルロード）の実行
• トランザクションをチェックし、データ更新（CDC）
• カットオーバー時にアプリケーションを停止
• 差分データが適用されたことを確認
• アプリケーションを再開

DMSのデータ検証機能

• データ移行とは非同期で実行可能
• 主キー／ユニークキーが存在するテーブルのみ設定可能
• ソースDBとターゲットDBのデータの各行が一致しているか確認する

まとめ

• どの方法がベストか考える
• アセスメントにSCTが有効
• SCTでコードオブジェクトを移行
• DMSでデータ移行
• データ整合性の検証には時間がかかる

感想

異なるDBエンジンへの移行時には、SCTが非常に便利です。
ある程度、自動変換してくれますし、また、手動変換が必要な場合も、Playbookを確認することで対応方法が分かる場合があります。
DB移行時に重要なのは、パフォーマンステストやアプリケーションが正常に動くかどうかのテストフェーズです。
SCTやDMSを利用することで、このテストフェーズに工数を割くことが可能になるかと思います！